1. Field of the Invention
The present invention pertains to communication networks. More particularly, this invention relates to providing a secure and transparent network gateway that does not require complex configuration to the associated firewall.
2. Description of the Related Art
In an open-ended network system such as Internet, a firewall is typically employed between servers and remote accessing clients (e.g., user terminals). The main purpose of the firewall is to control external accesses to and from the servers. This means that the firewall allows the external accesses to the servers to cross the firewall in a controlled fashion. FIG. 1 shows one such prior art arrangement of the firewall.
In FIG. 1, communication between the user terminal 11 and the target object servers 12 is conducted using Object Request Broker (ORB) transparent protocol over a TCP/IP (Transmission Control Protocol-Internet Protocol) communications protocol. When tie user terminal 11 wants to access a particular object in one of the target object servers 12, the terminal 11 uses an Interoperable Object Reference (IOR) to issue an object invocation using an object reference of the requested object. The object invocation is referred to as the user access request below. The object reference typically includes the TCP/IP port number and IP (Internal Protocol) address of the object. The port number and IP address specify the target object server that contains the requested object.
The firewall 13 has a number of TCP/IP ports and IP addresses, each configured or opened to correspond to one of the servers 12. When the user access request enters the firewall 13, the firewall 13 checks if the port and IP address specified in the user access request are opened in the firewall 13. If the port and IP address are opened in the firewall 13, the request passes through the firewall 13 and reaches the designation target object server. Then a communication channel can be established for transferring the requested object to the user terminal 11. If the firewall 13 does not have the corresponding port opened, the firewall 13 does not let the user access request to pass through it and does not establish communication channel for the user access request.
One disadvantage of this prior art firewall is that the firewall has statically configured target object ports and IP addresses. Adding new target object servers requires reconfiguration of the firewall. This can only be done by opening new ports and IP addresses. For security reasons, these ports and IP addresses cannot be opened ahead of time because it creates security loopholes. This means that the firewall does not have any flexibility.
One prior solution to solving the problem of accessing the target objects is to employ a CORBA (Common Object Request Broker Architecture) gateway behind the firewall, as can be seen from FIG. 2. The CORBA gateway can also be implemented as part of the firewall. One such prior CORBA gateway is the Wonderwall manufactured and sold by Iona Technologies PLC from Ireland.
In FIG. 2, the firewall 22 is configured to have one port number and IP address designated to the CORBA gateway 23. All user access requests to the servers 24 are forwarded to the CORBA gateway 23 by the firewall 22. The CORBA gateway 23 maps all of the servers 24. Each of the target object servers 24 has an individual IP address and at least one port number. The CORBA gateway 23 includes a mapping lookup table that specifies the port numbers and IP addresses of all the servers 24 connected to the CORBA gateway 23. Each pair of port number and IP address stored in the mapping lookup table of the CORBA gateway 23 can be retrieved from the lookup table using an object key. The object key is part of the object reference from the user access request. Whenever a user access request passes through the gateway 23, the request has to be examined and routed by the gateway 23 according to the content of the object key in the user access request.
In order for a user access request to access a particular target object server, the object reference of the access request is first proxified at the user terminal (e.g., terminal 21) using the IOR such that the proxified request points to the CORBA gateway 23, instead of the intended target object server. The proxification is done by specifically replacing the port number and IP address of the object reference used by the user access request that point to the particular target object server with the port number and IP address of the CORBA gateway 23. To access the target object server, a TCP/IP connection between the user terminal (e.g., the terminal 21) and the gateway 23 must first be established. This is done through the ORB protocol in the user terminal 21 upon receiving the object reference from the client application. In this case, the firewall 22 must have the IP address and port configured in order for the TCP/IP connection to go through. Once the TCP/IP connection is established, the ORB protocol in the user terminal 21 sends the request that contains the object key in the request header.
At the CORBA gateway 23, the server port number and IP address are extracted from the request header by using the object key of the access request to search the mapping lookup table in the CORBA gateway 23. The CORBA gateway 23 establishes another connection (i.e., gateway-target object server) and forwards the request over this connection to the target object server. This dynamically maps the port number and IP address of a particular target object server to the CORBA gateway 23.
However, disadvantages are associated with the prior CORBA gateway. One disadvantage associated is that the gateway typically does not allow the firewall to provide end-to-end security for the communication (e.g., authentication, confidentiality, and integrity). This means that SSL (secure socket layer) protocol cannot be used, for example, between the firewall 22 and the servers 24 as a single session. This is due to the fact that the CORBA gateway requires access to request header in order to extract the object key. Connections have to be terminated at the firewall/gateway and encrypted data have to be decrypted to allow examination of the object reference headers and to make filtering decisions. If SSL is used, secure communication can only establishes two separate sessions. One of which is between the user terminal and the firewall and the other is between the firewall and the target object servers. This means that a single SSL session cannot be established between the user terminal and the target object servers. As a consequence, encryption of data cannot be preserved from end-to-end. There is no direct authentication between the user terminal and the target object servers. The gateway has to be trusted to pass client and target object server credentials (e.g., identity certificate). However, this credential must be passed as additional payload. This means that the target object server must be modified to manage user credentials.
Another disadvantage is that the configuration of access control list based on object keys of the prior CORBA gateway is static, complex, and manual. Moreover, the prior CORBA gateway does not provide a mechanism for authenticating clients and target object servers at the firewall. Depending on security policy, the client authentication may be necessary at the firewall before commencing traffic to the target object servers. This protection is necessary for malicious outside attacks and the firewall creates a first line of defense. Authenticating target object servers at the firewall may be necessary in situations where security policy requires that an authorized resource is available at the target address, not a Trojan horse. A client or user terminal may use a Trojan horse to penetrate Internet network.
One feature of the present invention is to provide a secure and transparent network connection for an open-ended network system.
Another feature of the present invention is to provide a secure and transparent network gateway that does not require complex configuration to the associated firewall.
A further feature of the present invention is to provide a secure and transparent network gateway that simplifies the proxification of Interoperable Object References (IORs) and does not expose dynamically assigned ports of the gateway to external client applications.
A still further feature of the present invention is to provide a secure and transparent network gateway that maps a dynamically assigned gateway port to specific destination IP and port at the servers.
A method of allowing a secure and transparent communication between a user device and servers of a data access network system via a firewall and a gateway is described. The method includes the step of designating a plurality of ports in the firewall for the gateway, each corresponding to one of a number of ports in the gateway. Each of the gateway ports can be dynamically assigned to correspond to the port and IP address of one of the servers. The method also includes a step of proxifying an object reference that refers to a target server of the servers to be accessed by a user request from the user device in order to allow a single end-to-end secure session between the user device and the target server to be established via the gateway. This step is performed by first replacing the IP address and the port number of the target server of the user request with a dynamically assigned gateway port and the IP address of the gateway. Then the dynamically assigned gateway port and the gateway""s IP address are mapped to the port of and IP address of the target server such that the user request is not required to expose the IP address and port number of the target server and the single end-to-end secure session between the user device and the target server is established.
In a data access network system having servers, a client access device, a firewall, and a first and a second gateway serially coupled between the servers and the firewall, a method of establishing secure connection between the client device and a target server of the servers is described. The method includes the step of designating a plurality of ports in the firewall for the first gateway, each corresponding to one of a number of ports in the first gateway. Each of the gateway ports of the first gateway can be dynamically assigned to correspond to a port of the second gateway. Each of the gateway ports of the second gateway can also be dynamically assigned to correspond to a port of the servers. The method also includes a step of proxifying an object reference that refers to the target server to be accessed by a user object invocation request from the user device in order to establish a single end-to-end secure session between the user device and the target server. This step is performed by (1) replacing the IP address and the port number of the target server within the object reference with a dynamically assigned gateway port and the IP address of the first gateway, (2) mapping the dynamically assigned gateway port and the first gateway""s address to a dynamically assigned gateway port and the IP address of the second gateway, and (3) mapping the dynamically assigned gateway port and the IP address of the second gateway to the port and IP address of the target server such that the user request is not required to carry the IP address and port number of the target server. Once the object reference is proxified and proper mapping at the gateway is established, the user then may issue an object invocation request using the proxified object reference. When the user transmits the object invocation request by the client application in the user terminal, a chain of TCP/IP connections (i.e., user terminal-gateway, gateway-gateway, gateway-object) is established from the user terminal. Once such chain of TCP/IP connections is established, the underlying client application in the user terminal establishes over these connections a single SSL session with the target object server. After the SSL connection is established, the user""s object invocation request is sent.